I executed git pull --rebase origin main to see if build steps in autodiff job finish successfully after enzyme submodule update

No problem found

cc @jieyouxu

@bors try jobs=x86_64-gnu-autodiff

Rerunning to test potential cache effects.
Once this is done, we should ping Jakub and jieyouxu to discuss where to put it (and probably create an infra thread to discuss). I also don't think they'll accept autodiff as a culprit of measurably longer PR CI, so we'll probably need to move it, if the cache isn't helping enough.

☀️ Try build successful (CI)
Build commit: d1a9718 (d1a971826b83fead3b7550c5e4440c9102bb3290)
Base parent: 3c00c96 (3c00c96d3af4d5b5e101e56cc161a608b21366ee)

Rebuilding a second time, since I'm not sure if artifacts are shared between PR Ci and try runs.
@bors try jobs=x86_64-gnu-autodiff

But so far, even just building LLVM+rustc+std+enzyme takes 95 minutes, 10 minutes more than miri, the next slowest job. Total time will always be a bit more than that, and autodiff will always have less users than something general like Miri, so that's hard to defend.

If the try results come back unchanged, can you move it to auto and mark it as allowed to fail? I don't think it needs to be blocking yet.

☀️ Try build successful (CI)
Build commit: 96310de (96310dea88820c3264b54ee2b5011698005372aa)
Base parent: 36714a9 (36714a9983d6ba11203d8bb87a1b372247fbcf06)

@bors try jobs=x86_64-gnu-autodiff

☀️ Try build successful (CI)
Build commit: 7215d1b (7215d1be8eb0e150e6d50a7fe36403cec80dbf4f)
Base parent: cb014fc (cb014fcb149e44d8aa16a8f66c9f2b1762f034f8)

@ZuseZ4
Would you be comfortable making this job required from the start by removing continue_on_error: true?
I reran autodiff tests with the latest main branch and they succeeded. That means llvm ir checks updates in #156777, which I created 3 weeks ago, are still fine against the latest main

submodule updates are meant to be trivial so those not breaking us doesn't mean much. There's an open update to llvm23, can you test if that breaks something?

But I generally wouldn't want to block this on an MCP and (for now) I'd rather like us to chase optional CI failures since that's up to us, rather than pushing bugfixes onto other people, at least for now.

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Some changes occurred in src/tools/enzyme

cc @ZuseZ4

This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp.

Some changes occurred in coverage tests.

cc @Zalathar

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

@bors try jobs=optional-x86_64-gnu-autodiff

☀️ Try build successful (CI)
Build commit: 1d0455a (1d0455a9c97b86ae095c59bec7ef269ff1a58886)
Base parent: 4a9d536 (4a9d5368df6450bbd2fc8dde4508c3e5d83bb19d)

All autodiff tests passed on top of the LLVM 23 update in #158734.
I also restored continue_on_error: true, so the job remains optional.
I’ll keep an eye on the job and investigate any failures.